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SYSTEM AND METHOD FOR ACCESSING A SOCKS SERVER FROM AN END 
USER WORKSTATION IN AN IP NETWORK 

Technical field of the invention 

5 The present invention relates to computer networks, and 

more particularly to a method and system for setting the value 
of the Type Of Service (TOS) field of an IP Datagram according 
to the Application Level protocol used by Socks data in an end 
user workstation attached to an Internet Protocol (IP) 
10 network. 

Background art 

INTERNET 

The Internet is a global network of computers and 
computers networks (the "Net") . The Internet connects 

15 computers that use a variety of different operating systems or 
languages, including UNIX, DOS, windows, Macintosh, and 
others. To facilitate and allow the communication among these 
various systems and languages, the Internet uses a language 
referred to as TCP/IP ("Transmission Control Protocol/Internet 

20 Protocol"). TCP/IP protocol supports three basic applications 
on the Internet : 

• transmitting and receiving electronic mail, 

• logging into remote computers (the "Telnet"), and 

• transferring files and programs from one computer to 
25 another ("FTP" or "File Transfer Protocol"). 

TCP/IP 

The TCP/IP protocol suite is named for two of the most 
important protocols: 

• a Transmission Control Protocol (TCP) , and 
30 • an Internet Protocol (IP) . 
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Another name for it is the Internet Protocol Suite. The 
more common term TCP/IP is used to refer to the entire 
protocol suite. The first design goal of TCP/IP is to build an 
interconnection of networks that provide universal 
5 communication services: an internetwork, or internet. Each 
physical network has its own technology dependent 
communication interface, in the form of a programming 
interface that provides basic communication functions running 
between the physical network and the user applications. The 

10 architecture of the physical networks is hidden from the user. 
The second goal of TCP/IP is to interconnect different 
physical networks to form what appears to the user to be one 
large network. 

TCP is a transport layer protocol providing end to end 

15 data transfer. It is responsible for providing a reliable 

exchange of information between 2 computer systems. Multiple 
applications can be supported simultaneously over one TCP 
connection between two computer systems. 

IP is an internetwork layer protocol hiding the physical 

20 network architecture bellow it. Part of the communicating 

messages between computers is a routing function that ensures 
that messages will be correctly directed within the network to 
be delivered to their destination. IP provides this routing 
function. An IP message is called an IP Datagram. 

25 Application Level protocols are used on top of TCP/IP to 

transfer user and application data from one origin computer 
system to one destination computer system. Such Application 
Level protocols are for instance File Transfer Protocol (FTP) , 
Telnet, Gopher, Hyper Text Transfer Protocol (HTTP) . 

30 IP ROUTER 

A "Router" is a computer that interconnects two networks 
and forwards messages from one network to the other. Routers 
are able to select the best transmission path between 
networks. The basic routing function is implemented in the IP 
35 layer of the TCP/IP protocol stack, so any host (or computer) 
or workstation running TCP/IP over more than one interface 
could, in theory, forward messages between networks. Because 
IP implements the basic routing functions, the term "IP 
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Router" is often used. However, dedicated network hardware 
devices called "Routers" can provide more sophisticated 
routing functions than the minimum functions implemented in 



IP. 



WORLD WIDE WEB 

With the increasing size and complexity of the Internet, 
tools have been developed to help find information on the 
network, often called navigators or navigation systems. 
10 Navigation systems that have been developed include standards 
such as Archie, Gopher and WAIS. The World Wide Web ( "WWW" or 
"the Web") is a recent superior navigation system. The Web is 

• an Internet -based navigation system, 

15 • an information distribution and management system for the 
Internet, and 

• a dynamic format for communicating on the Web. 
The Web seamlessly, for the use, integrates format of 
information, including still images, text, audio and video.. A 

20 user on the Web using a graphical user interface ("GUI", 
pronounced "gooey") may transparently communicate with 
different host computers on the system, and different system 
applications (including FTP and Telnet) , and different 
information formats for files and documents including, for 

25 example, text, sound and graphics. 

HYPERMEDIA 

The Web uses hypertext and hypermedia. Hypertext is a 
subset of hypermedia and refers to computer-based "documents" 
in which readers move from one place to another in a document, 

30 or to another document, in a non- linear manner. To do this, 
the Web uses a client - server architecture. The Web servers 
enable the user to access hypertext and hypermedia information 
through the Web and the user's computer. (The user's computer 
is referred to as a client computer of the Web Server 

35 computers.) The clients send requests to the Web Servers, 
which react, search and respond. The Web allows client 
application software to request and receive hypermedia 
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documents (including formatted text, audio, video and 
graphics) with hypertext link capabilities to other hypermedia 
documents, from a Web file server. 

The Web, then, can be viewed as a collection of document files 
residing on Web host computers that are interconnected by 
hyperlinks using networking protocols, forming a virtual "web" 
that spans the Internet. 

UNIFORM RESOURCE LOCATORS 

A resource of the Internet is unambiguously identified by 
a Uniform Resource Locator (URL) , which is a pointer to a 
particular resource at a particular location. A URL specifies 
the protocol used to access a server (e.g. HTTP, FTP,..), the 
name of the server, and the location of a file on that server. 

HYPER TEXT TRANSFER PROTOCOL 

Each Web page that appears on client monitors of the Web 
may appear as a complex document that integrates, for example, 
text, images, sounds and animation. Each such page may also 
contain hyperlinks to other web documents so that a user at a 
client computer using a mouse may click on icons and may 
activate hyperlink jumps to a new page (which is a graphical 
representation of another document file) on the same or a 
different Web server. 

A Web server is a software program on a Web host computer 
that answers requests from web clients, typically over the 
Internet. All Web use a language or protocol to communicate 
with Web clients which is called Hyper Text Transfer Protocol 
("HTTP") . All types of data can be exchanged among Web servers 
and clients using this protocol, including Hyper Text Markup 
Language ("HTML"), graphics, sound and video. HTML describes 
the layout, contents and hyperlinks of the documents and 
pages. Web clients when browsing : 

• convert user specified commands into HTTP GET requests, 

• connect to the appropriate Web server to get information, 
and 
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• wait for a response. The response from the server can be 
the requested document or an error message. 

After the document or an error message is returned, the 
connection between the Web client and the Web server is 
5 closed. 

First version of HTTP is a stateless protocol. That is 
with HTTP, there is no continuous connection between each 
client and each server. The Web client using HTTP receives a 
response as HTML data or other data. This description applies 
10 to version 1 . 0 of HTTP protocol, while the new version 1.1 
break this barrier of stateless protocol by keeping the 
connection between the server and client alive under certain 
conditions . 

BROWSER 

15 After receipt, the Web client formats and presents the 

data or activates an ancillary application such a sound player H 
to present the data. To do this, the server or the client 
determines the various types of data received. The Web Client 
is also referred to as the Web Browser, since it in fact 

20 browses documents retrieved from the Web Server. 

DOMAIN NAMES 

The host or computers names (like www.entreprise.com) are 
translated into numeric Internet addresses (like 194.56.78.3), 
and vice versa, by using a method called DNS ("Domain Name 
25 Service") . DNS is supported by network- resident servers, also 
known as domain name servers or DNS servers. 

INTRANET 

Some companies use the same mechanism as the web to 
communicate inside their own corporation. In this case, this 
30 mechanism is called an -intranet". These companies use the 
same networking/ transport protocols and locally based Web 
servers to provide access to vast amount of corporate 
information in a cohesive fashion. As this data may be private 
to the corporation, and because the members of the company 
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still need to have access to public Web information, to avoid 
that people not belonging to the company can access to this 
private Intranet coming from the public Internet, they protect 
the access to their network by using a special equipment 
5 called a Firewall. 

FIREWALL 

A Firewall protects one or more computers with Internet 
connections from access by external computers connected to the 
Internet. A Firewall is a network configuration, usually 
created by hardware and software, that forms a boundary 
between networked computers within the Firewall from those 
outside the Firewall. The computers within the Firewall form a 
secure sub-network with internal access capabilities and 
shared resources not available from the outside computers. 

Often, the access to both internal and external computers 
is controlled by a single machine, said machine comprising the 
Firewall. Since the computer, on which the Firewall is, 
directly interacts with the Internet, strict security measures 
against unwanted access from external computers are required. 

A Firewall is commonly used to protect information such 
as electronic mail and data files within a physical building 
or organization site. A Firewall reduces the risk of intrusion 
by unauthorized people from the Internet. The same security 
measures can limit or require special software for people 
inside the Firewall who wish to access information on the 
outside. A Firewall can be configured using "Proxies" or 
"Socks" to control the access to information from each side of 
the Firewall . 

PROXY SERVER 

A HTTP Proxy is a special server that typically runs in 
conjunction with Firewall software and allows an access to the 
Internet from within a Firewall. The Proxy Server : 

• waits for a request (for example a HTTP request) from 
inside the Firewall, 



FR 9 99 087 6 

BNSOOCID: <E1 994801 01 03> 



10 



15 



20 



25 



• forwards the request to the remote server outside the 
Firewall, 

• reads the response, and 

• sends the response back to the client. 

5 

I A single computer can run multiple servers, each server 

1 connection identified with a port number. A Proxy Server, like 

\ an HTTP Server or a FTP Server, occupies a port. Typically, a 

| connection uses standardized port numbers for each protocol 

f 10 (for example, HTTP = 80 and FTP = 21) . That is why an end user 

has to select a specific port number for each defined Proxy 
Server. Web Browsers usually let the end user set the host 
name and port number of the Proxy Servers in a customizable 
I panel. Protocols such as HTTP, FTP, Gopher, WAIS, and Security 

j 15 can usually have designated Proxies. Proxies are generally 

* preferred over Socks for their ability to perform caching, 
high-level logging, and access control, because they provide a 
specific connection for each network service protocol. 

SOCKS AND SOCKS SERVER 
20 Socks is a protocol which does some form of encapsulation 

of Application Level protocols (for instance FTP, Telnet, 
Gopher, HTTP). Using Socks,, the Application Level, traffic 
between a system running a Socks Client software and a system 
running a Socks Server software is encapsulated in a virtual 
25 Socks tunnel between both systems. Socks is mainly used by 

systems within an Intranet in order to gain a secure access to 
systems located outside the Intranet. 

A Socks Server acts as a relay between the systems within 
the Intranet and the systems outside the intranet, thus hiding 
4 30 the internal systems from the external Internet. It is 

1 considered as one form of Firewall. 

A Socks Server (also called Socks Gateway) is a software 
that allows computers inside a Firewall to gain access to the 
Internet. A Socks Server is usually installed on a server 
35 positioned either inside or on the Firewall. Computers within 
the Firewall access the Socks Server as Socks Clients to reach 
the Internet. Web Browsers usually let the end user set the 
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host name and port number of the Socks Servers in a 
customizable panel. On some Operating Systems, the Socks 
Server is specified in a separate file (e.g. socks. conf file). 
As the Socks Server acts a layer underneath the protocols 
5 (HTTP/ FTP, ..)/ it cannot cache data (as Proxy does), because 
it doesn' t decode the protocol to know what kind of data it 
transfers . 



DISPATCHER SYSTEM 

10 When multiple Firewalls are used to gain access to 

systems outside the Intranet, a dedicated device called 
"Dispatcher System" is often used within the Intranet for 
dispatching the traffic to these multiple Firewalls. The main 
goal of the Dispatcher System is to balance the load across 

15 the multiple Firewalls. For instance when a very powerful 
Firewall and a smaller Firewall are available, more traffic 
should be dispached on the very powerful Firewall than on the 
smaller one. Such Dispatcher Systems are either dedicated 
hardware devices, or software components installed on existing 

20 network device (such as an IP Router) . 

More explanations about the technical field presented in 
the above sections can be found in the following publications 
incorporated herewith by reference: 

• "TCP/IP Tutorial and Technical Overview" by Martin W. 
25 Murhammer, Orcun Atakan, Stefan Bretz, Larry R. Pugh, 

Kazunari Suzuki, David H. Wood, International Technical 
Support Organization, October 1998, GG24 -337 6 - 05 . 

• "Javja Network Programming" by Elliot te Rusty Harold, 
published by O'Reilly, February 1997. 

30 • "Internet in a nutshell" by Valerie Quercia, published by 

O'Reilly, October 1997. 

• "Building Internet Firewalls" by Brent Chapman and 
Elizabeth Zwichky, published by O'Reilly, September 199 5. 

PROBLEM 
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The problem is to differentiate the IP Datagrams 
transporting Socks data according to the Application Level 
Protocol used by said Socks data. By nature, the Socks 
protocol is a form of encapsulation of Application Level 

§ — fe-2= a -f-§4c— such— as— H-T-TiP-,— Er£P-,— ! Telnet — When_Socks_S.erv_ers_ar.e_uaed- 

within an Intranet to provide secure access to systems located 
outside the Intranet, IP routers and network devices within 
this intranet only see and handle Socks traffic. As a 
consequence, all Application Level protocols encapsulated by 

10 Socks are treated alike within the TCP/IP network. 

When multiple Socks Servers are used within the Intranet 
to access systems outside the Intranet, a dedicated device 
called "Dispatcher System" is often used for dispatching the 
traffic on these multiple Socks Servers. The purpose of such 

15 Dispatcher System is mainly to balance the load across the 
multiple Socks Servers. For instance when a very powerful^ 
Socks Server and a smaller Socks Servers are available, more 
traffic can be dispatched on the very powerful Socks Server 
than on the smaller one. In a Socks environment, the 

20 Dispatcher System usually only sees and process Socks traffic 
and does not see the Application Level traffic which is 
encapsulated by Socks. As a consequence, all Application Level 
protocols such as HTTP, FTP, Telnet, are then treated alike by 
the Dispatcher System. To solve this problem, the Dispatcher 

25 System and any other IP network devices such as IP Routers can 
use the Type Of Service (TOS) field in the Header of the IP 
Datagrams comprising Socks data. For instance, based on the 
TOS field, interactive Telnet traffic can be processed by a 
Dispatcher System with a higher priority than batch FTP 

30 traffic. For instance, this Telnet traffic can be dispatched 
on a high capacity Socks Server while the FTP traffic is 
dispatched on a smaller Socks Server. 

The problem is then to set the value of the Type Of 
Service (TOS) field in IP Datagrams comprising Socks data, 

35 according to the Application Level protocol used in said IP 
Datagrams . 

The current solutions address this problem partially: 
FR 9 99 087 9 
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• The Type Of Service (TOS) field can be set by any network j 

f 

device according to the protocol of the TCP data transported \ 
in the IP Datagrams. That protocol is identified by the ' 
Destination Port field of the TCP Header within the IP 

* 

5 Datagram. The major drawback is: | 

$ 

! 

• In a Socks environment, the protocol of the TCP data j 
transported in IP Datagrams is always the Socks protocol . 

As a consequence, the TOS field has always the same value 
which corresponds to the Socks protocol. The TOS field is j 
10 therefore not representative of the Application Level ! 

protocol of Socks data. For instance, IP Datagrams 

transporting HTTP, FTP, or Telnet data over Socks have \ 
all the same TOS value. The Type Of Service (TOS) field 
cannot be used to differentiate the IP Datagrams \ 
15 according to the Application Level protocol of Socks data 

since this field has always the same unique value. 

♦ The Type Of Service (TOS) field can be set by a network I 

I 

device, for instance a Router. The mam drawbacks of this 
solution are the following: 

20 • The association between Type Of Service (TOS) value and 1 

Application Level protocol is then done by a network ; 

device within the intranet, and not by the end user I 

workstation. Some Service Providers may not use such j 

network device within their IP network. As a consequence, | 

25 companies which are not owner of their Intranet network i 

but which lease it to such Service Providers, will not * 

i 

take advantage of this solution. 

i 

• The network devices have to maintain connection tables to 
associate the TOS value with the Application Level 

30 protocol of each IP Datagram transporting Socks data. 

Maintaining such tables requires some processing capacity 
and therefore has an impact on the performance of the 
network devices. Furthermore, such tables require a large 
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amount of memory on these network devices, which is very- 
costly. 

• To each Application Level protocol corresponds one and 

orrl"y~on-e — TOS - valixe~ — Howe^er~s~ome~ groap"s~~c>f~ end-u'sers 

5 may need to use specific Type Of Service (TOS) values 

different to the Type Of Service (TOS) values already 
used by the other end users for the same Application 
Level protocols. This is not possible with this solution. 
For example, all end users within the Intranet will use 
10 the same low priority (deducted from TOS field within the 

network) for their FTP traffic, although one group may 
specifically need a high priority for its FTP traffic. 

Objects of the invention 

15 • An object of the present invention is to set the value of 
the Type Of Service (TOS) field in IP Datagrams comprising 
Socks data, according to the Application Level protocol used 
by said Socks data from an end user workstation within an IP 
network . 

20 • It is a further object of the present invention to 

differentiate Socks traffic using the Type Of Service (TOS) 
field. 

• It is another object of the present invention to optimize 
performance and availability of WEB access via Socks 
25 Servers, by differentiating Socks traffic based on the TOS 

field value. 



Summary of the invention 

The present invention discloses a method and system, in a 
source device, for setting the value of a Type of Service 
30 (TOS) field in an Internet Protocol (IP) datagram according to 
the application protocol level of socks data transported in 
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this IP datagram. This IP datagram is sent from a source 
application on a source device to a destination application on 
a destination device. The present method comprises the steps 
of: 



5 • identifying the source device, 

• identifying the destination device, 

• identifying the application on the source device, 

• identifying the application on the destination device, 

• determining a Type of Service (TOS) value referring to a 
10 first table, said first table comprising for each socks 

connection identified by: 

• a source device address, 

• a destination device address, 

• a source application address, and 
15 ♦ a destination application address, 

a Type Of Service (TOS) value. 

• writing the Type Of Service (TOS) value in the Type Of 
Service (TOS) field of the IP datagram. 

If the IP datagram comprises a message for establishing a 
20 new socks connection, the step of determining a Type Of 
Service (TOS) value comprises the preliminary steps of: 

• updating the first table with the new socks connection 
identified by: 

• the source device address, 

25 • the destination device address, 

• the source application address, 

• the destination application address, 
of the IP datagram, 

• identifying the application level protocol from the IP 
30 datagram, 

• determining a Type of Service (TOS) value referring to a 
second table, said second table comprising for each 
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application level protocol a Type Of Service (TOS) value, 

• associating in said first table said socks connection 
with said Type Of Service (TOS) value. 

The method comprises the further step of configuring this 
second table, this second table being preferably retrieved 
from a server system within the network. 



Drawings 

The novel and inventive features believed characteristics 
10 of the invention are set forth in the appended claims. The 

invention itself, however, as well as a preferred mode of use, 
further objects and advantages thereof, will best be 
understood by reference to the following detailed description 
of an illustrative detailed embodiment when read in 
15 conjunction with the accompanying drawings, wherein : 

• Figure 1 is a logical view of an end user system accessing 
the World Wide web, according to prior art. 

• Figure 2 is a general view of an end user system accessing 
the World Wide Web according to prior art. 

20 • Figure 3 shows an IP Datagram according to prior art. 

• Figure 4 is a general view of a Socks Client with a 
plurality of Socks Servers according to prior art. 



• Figure 5 is a general view of an end user workstation 
retrieving from an Auto TOS System the Type Of Service (TOS) 

25 values associated with the Application Level protocols used 
by Socks data according to the present invention. 

• Figure 6 is an internal view of an end user workstation 
according to the present invention. 
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• Figure 7 shows the tables used by the Socks TOS Client 
according to the present invention, 

• Figure 8 is a flow chart of the TOS Definition Builder 
component, according to the present invention. 

5 • Figure 9 is a flow chart of the Socks Traffic Analyser 
according to the present invention, 

• Figure 10 is a flow chart of the Socks TOS Finder according 
to the present invention. 

• Figure 11 is a flow chart of the Socks TOS Builder according 
10 to the present invention. 

Preferred embodiment of the invention 

ACCESS TO THE WORLD WIDE WEB 

Logical View 

Figure 1 shows a user system with a user interface (102) 
comprising a Web Browser (101) for accessing the 
World -Wide -Web (WWW) . The www content is transferred using the 
HTTP protocol. HTTP requests and responses are exchanged 
between the Web Browser program (101) and a destination Web 
Server (103) containing the WWW information the user wants to 
access. The Socks Server (104) between the Web Browser (101) 
and the Web Server (103) acts as an intermediary HTTP Relay 
forwarding the HTTP requests and responses to their 
destination. The Web Browser program (101) makes an HTTP 
request to the Socks Server (104) and the Socks Server 
forwards the- request to the destination Web Server (103). The 
flow in the reverse direction (HTTP response) again goes via 
the Socks Server (104) to the Web Browser (101) . In this way 
the Socks Server can limit the traffic to authorised 
transactions according to its configuration (based on some 
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defined security and access control policy) . The Socks Server 
hence protects the network where Web Browser is located. 



Physical view 

Figure— 2— is— a— phys-te ai— view— of— the— setr--H-p— 1-og-i-cai-l-y 

5 described in Figure 1. In this particular example, the Web 
Browser (201) runs on a system (workstation) connected to an 
intranet (202) network. The Intranet network comprises network 
devices such as IP Routers (206) . The Socks Servers (203) 
protecting the Intranet connect both the (private) Intranet 

10 (202) and the (public) Internet (204). the destination Web 
Server (205) is also connected to the Internet, It is 
important to note that Socks Servers attach two networks and 
hence act as intermediaries for communications between said 
two networks. Multiple Socks Servers are often used in order 

15 to provide access robustness and load sharing. 

IP DATAGRAM 

The transfer unit of a data packet in TCP/IP is called an 

IP Datagram. It is made up of a header containing information 

for IP protocol and data that is only relevant to the higher 

20 level protocol. Figure 3 shows the format of a IP Datagram, in 
the environment described in Figures 1 and 2 : 



• (301) IP Datagram, an IP Datagram is a message exchanged 
between 2 computer systems across a TCP/IP network. An IP 
Datagram is divided in 2 parts : 



25 



a Header, 



and 



• Data. 



(302) IP Datagram Header, the header comprises fields 



such as : 



30 



the Type Of Service (TOS) field (310) . The Type Of 
Service (TOS) field (310) is an indication of the 
quality of service requested for the IP Datagram. It 
can be used to provide the nature and the priority of 



FR 9 99 087 



15 




the IP Datagram. It can be set either by the system 
initiating the connection (the origin) , or on the fly 
by a network device (for instance an IP Router) within 
the network. 

5 • the Source IP Address (312) (the IP address of the 

computer which sends the IP Datagram) . 

• the Destination IP Address (the IP address of the 
computer which is the destination of the IP Datagram) . 

• The Header Checksum (311) is used by the destination of 
10 the IP datagram for checking that all fields in the IP 

Datagram Header have not been altered in the network. 
The Header Checksum is a combination of all fields in 
the IP Datagram Header. 

The IP Datagram Header is mainly used to route the IP 
15 Datagram to its final destination. 

• (303) IP Datagram Data. This field comprises the data 
sent by the originator to the destination computer 
system. The destination computer system processes this 
data. Since the TCP/IP protocol suite is organised in 
20 layers, the IP Datagram field comprises the message 

relevant to the higher level protocol (which is TCP in 
the environment related to the invention) . 

• (304) TCP Segment. A TCP message is usually called TCP 
Segment . 

25 • (305) TCP Header. A TCP Header comprises fields such 

as the Source Port (314) and the Destination Port 
(Dest Port) (315) which identify the application 
protocol (e.g. HTTP, FTP, Telnet, Socks) transported 
by TCP. This field is mainly used by the destination 

30 of the IP Datagram to determine which application 

must process the data transported by TCP. 

♦ (306) TCP Data. The TCP Data field comprises 

application data which are sent by the originator to 
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the destination computer system. The destination 
computer system processes the data- Since the TCP/IP 
protocol suite is organised in layers, the TCP Data 
part contains the information relevant to the higher 
-1-evel— protocol— which— i-s— the- Appl-i-ea-t-i-on— level 



protocol (such as HTTP, FTP, Telnet, Socks) 



• (307) Application Level Message. The TCP Data part 
of the IP Datagram contains an Application Level 
Message, This is for example a Socks message (for 

10 instance a "CONNECT" or a "BIND" message) , a HTTP 

message, a FTP message, or a Telnet message. 
Depending on the Application level protocol, this 
Application Level Message can also be split in 2 
parts. 

15 ♦ (308) Application Level Header. The Application 

Level Header is the header relevant to the 
application protocol such as HTTP, FTP, Telnet. 

• (309) Application Level Data. This is the data 
part which is processed by the application 

20 responsible of handling the Application Level 

protocol. This is usually the data which is 
directly relevant to the end user (for instance, 
data entered by an end user on his workstation) . 



SOCKS CLIENT AND SOCKS SERVER 

25 A Socks is a networking proxy protocol that allows client 

workstations to gain full access to hosts outside their local 
network while providing a high degree of security. Figure 4 
shows an end user workstation (401) connected to an Intranet 
(402). The Socks Servers (403) that protect the Intranet 

30 attach both the (private) Intranet (402) and the (public) 

Internet (404) . The destination Web System (405) also connects 
the Internet (the Web System is for instance a WEB Browser, a 
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FTP Server, or any system attached to the Internet that can be 
accessed from the Intranet) . 

The end user workstation (401) comprises a software 
5 program called Socks Client (406) for a secure access to the 
World -Wide -Web (WWW) via a Socks Server, The Socks Client 
creates some form of "virtual tunnel" between workstation and 
Socks Server. The Socks protocol is independent of the 
Application Level protocol/ and can therefore be used for 
10 instance for HTTP, FTP, or Telnet communications. 

When multiple Socks Servers (403) are used to access 
WEB Systems on the Internet, a Dispatcher System (411) is 
often used to balance the traffic load across the multiple 
Socks Servers. End user workstations (401) are then accessing 
15 the plurality of Socks Servers (403) by means of this single 
Dispatcher System which acts as one virtual single Socks 
Server. 

The IP Router (410) within the Intranet routes each IP 
Datagram it receives towards its destination. The IP Router 

20 determines the next hop (413), using the Destination IP 
Address field in the IP Datagram Header. 

WEB applications running on an end user workstation (such 
as a WEB Browser (407), an FTP Client (408), or a Telnet 
Client (409)) use the services of a Socks Client (406) to gain 

25 access to an outside WEB System (405) . The Socks Client 
located on the end user workstation sends (412) each IP 
Datagram on the Intranet network to a destination Socks 
Server. IP Routers within the Intranet receive the IP 
Datagrams and route them (413) towards their destination. The 

30 Dispatcher System (411) which is viewed by the Intranet as a 
Socks server receives the IP Datagrams. The Dispatcher System 
selects for each IP Datagram the "best" Socks Server, and 
forwards each IP Datagram to the selected Socks Server. The 
Socks Server authenticates the user, authorizes the request, 

35 establishes a connection (415) with the outside WEB System, 
and then transparently forwards application data between the 
end user workstation and the WEB System (416) . 

AUTO TOS SYSTEM 
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The present invention relates to a system and method for 
setting the Type Of Service (TOS) field of IP Datagrams 
transporting Socks data according to the Application Level 

protocol— used-by— sa-i-d-SoGk-s-da-fea-.— F-igur-e-5-, is-a-general— view 

5 of an end user workstation retrieving from an Auto TOS System 
the Type Of Service (TOS) values associated with the 
Application Level protocols used by Socks data according to 
the present invention. 

An end user workstation (501) comprising a Socks Client 

10 is connected to the intranet (502), said Intranet comprising 
multiple Socks Servers (503) for accessing the WEB System 
(505) connected to the Internet (504). An AutoTOS system (506) 
located within the Intranet (502) is in charge of providing 
the information (507) required for configuring end user 

15 workstations connected to the Intranet. Said information is 

comprised in a table called "TOS Definition table" (507) . This 
table associates each Application Level protocol used by Socks 
data with a Type Of Service (TOS) value. For instance, the TOS 
Definition table may associate the FTP protocol with a TOS 

20 value of 0, the Telnet protocol with a TOS value of 1, and the 
HTTP protocol with a TOS value of 7 . In a preferred 
embodiment, the TOS Definition table is a flat file and is 
created and maintained for instance by a Network 
Administrator. Before accessing (510) the World Wide Web, the 

25 end user workstation (501) gets connected (508) to the AutoTOS 
system and retrieves (509) the TOS Definition table located in 
said AutoTOS system using for instance the HTTP protocol or 
any file transfer protocol such as FTP. The TOS Definition 
table can be: 

30 ♦ statically defined on the AutoTOS system. In this case, 
the same TOS Definition table is retrieved by all end 
user workstations. This way, all end user workstations 
will use the same TOS values for the same Application 
Level protocols, therefore providing a consistent TOS 

35 definition within the whole Intranet. For instance, all 
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end user workstations within the network will use a TOS 
value of 0 for the FTP protocol. 

or dynamically built when the end user workstation 
requests the AutoTOS system to send back the TOS 
Definition table. The table can be for instance 
dynamically built by a CGI (Common Gateway Interface) 
computer program running on the AutoTOS system. 
The TOS Definition tables returned to the different end 
user workstations may be different according to some 
criteria such as the IP address of the end user 
workstation. For instance, one group of users (groupO) 
may use a TOS value of 0 for FTP, while another group of 
users (groupl) may use a TOS value of 1 for that same FTP 
protocol. IP Datagrams having a TOS value of 1 will be 
processed with a higher priority than IP Datagrams having 
a TOS value of 0. The FTP service provided to groupl will 
offer better performances than the FTP service provided 
to groupO . 

20 IP DATAGRAM ROUTING AND D I S PATHCHING 

Figure 6 is a view of the routing and dispatching of IP 
Datagrams according to the present invention. The end user | 
workstation (601) comprises: $ 

I 

25 • a Socks Client (606) , and f 
• a TCP/IP Stack (607) (the TCP/IP Stack is in charge of | 

processing all IP Datagrams on the workstation) . f 

1 
j 

This end user workstation is connected to the Intranet j 
30 (602), said Intranet comprising multiple Socks Servers (603) 

to access the WEB System (605) connected to the Internet j 

(604) . j 

A Dispatcher System (615) located within the Intranet is 
used to dispatch IP Datagrams transporting Socks data on Socks j 
35 Servers (603). The Dispatcher System which is viewed by the j 
Intranet network as a Sock Server, receives the IP Datagrams 
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originated by the end user workstation (601) - Then, it selects 
the "best" Socks Server where to forward the IP Datagrams, 
using information comprised in the Type Of Service (TOS) field 
in the IP Datagram Header. For instance an IP Datagram with a 

- T eS^vaiue-o^G-wil-l— be~f-or=wa-rd'ed— to-a— l-ow-eapae-i-fe-y—Seek-s- 



Server, while an IP Datagram with a TOS value of 7 will be 
forwarded to another more powerful Socks Server. The IP Router 
(614) receives (616) IP Datagrams from the end user 
workstation and routes then within the Intranet towards their 
10 destination. 

SOCKS TOS CLIENT 

The end user workstation comprises: 

• (606) a Socks Client. 
15 • (607) a TCP/IP Stack. The TCP/IP Stack processes all IP 

Datagrams, and is in particular in charge of sending all IP 
Datagrams to the Intranet. 

(608) a Socks TOS Client component according to the present 
invention. 

20 The Socks TOS Client determines for each IP Datagram a 

TOS value depending on the Application Level protocol used by 
the socks data transported in the IP Datagram and writte this 
TOS value in the Type Of Service (TOS) field of the IP 
Datagram. The Socks TOS Client is configured with a TOS 

25 Definition table associating with each Application Level 
Protocol, a particular TOS value. 

When the end user workstation must send an IP Datagram 
comprising Socks data to a Socks Server (603), the TCP/IP 
Stack (607) first forwards said IP Datagram to the Socks TOS 

30 Client (608) within the workstation. The IP Datagram is then 
forwarded in sequence to a plurality of other components 
within said Socks TOS Client to perform the method according 
to the present invention: 
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• (609) a TOS Definition Builder component builds the TOS 
Definition table (610) that is used by the Socks TOS 
Client to determine the TOS value of each IP Datagram 
comprising socks data. The TOS Definition table is 

5 preferably retrieved from the AutoTOS system described in 

Figure 5 by this TOS Definition Builder component. 

• (612) a Socks Traffic Analyser component analyses the IP 
Datagram and builds a Socks Connection table (611) with 
the characteristics of the Socks connections using the 

10 Application Level protocol of the IP Datagram jointly 

with information comprised in the TOS Definition table 
(610) . 

• (613) a Socks TOS Finder component determines the Type Of 
Service (TOS) field of the IP Datagram, based on the 

15 Socks Connection table (611) jointly with the Source IP 

Address, Source Port, Destination IP Address and 
Destination Port fields of the IP Datagram. 

• (614) a Socks TOS Builder component writes the value 
determined by the Socks TOS Finder component in the TOS 

20 field of the IP Datagram. 

The Socks TOS Client finally returns the IP Datagram to 
the TCP/IP Stack (607) component within the end user 
workstation. This TCP/IP component then sends (616) the IP 
Datagram towards its destination. The invention does not 

25 depends on the TCP/IP Stack component and does not rely on the 
way the IP Datagram is handled and forwarded by this TCP/IP 
Stack component. The IP Router (614) within the Intranet 
receives the IP Datagram and routes it (617) towards its 
destination. Possibly, the IP Router can process the IP 

30 Datagram according to the TOS field, using any existing 

mechanism (for instance IP Datagrams with a TOS of 7 can be 
routed faster than IP Datagrams with a TOS of 0) . The 
Dispatcher System (615) which receives the IP Datagram then 
selects the "best" Socks Server where to forward the IP 
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Datagram using for instance the Type Of Service (TOS) field in 
the IP Datagram Header, and then forwards (518) the IP 
Datagram to said "best" Socks Server. 



— 5 opriona-l-l-y— the-Socks~TOS-Cl~i-ent— can-be-ex-trended— {-for 

instance by means of a configuration parameter of the Socks 
TOS Client) to determine the TOS value and write this TOS 
value in the TOS field for all IP Datagrams. This way, not 
only IP Datagrams comprising Socks data can be processed by 

10 the Socks TOS Client. The Socks TOS Client then becomes a 
general "TOS Client" which is no longer specific to Socks 
traffic. In this case, the Application Level protocols 
. comprised in the TOS Definition table are not interpreted by 
the Socks TOS Client as protocols used by socks data (for 

15 instance HTTP transported by socks) but as protocols directly 
used by TCP data (for instance HTTP transported by TCP) . 

SOCKS TOS CLIENT INTERNAL TABLES 

Figure 7 depicts the different tables located in the end 
user workstation. These tables are used by the various 
20 components of the Socks TOS Client for analysing Socks data 
and for determining the value of the Type Of Service (TOS) 
field. The Socks TOS Client on the end user workstation uses a 
first table called TOS Definition table (701) created: 

• either, on an AutoTOS System (506) (for instance by a 

25 Network Administrator) . The table is then downloaded from 
the AutoTOS System to the end- user workstation. 

• or, directly on the end user workstation (for instance 
manually), before starting the Socks TOS Client. 



30 • (701) TOS Definition table. This table comprises for each 
Application Level Protocol, the value that must be 
written in the Type Of Service (TOS) field of the IP 
Datagram. 
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The Socks TOS Client uses for internal purpose a second 
table which is dynamically built: 

♦ (705) Socks Connection table. This table comprises the 
originator and the Type Of Service (TOS) of each Socks 

5 connection. 

These two internal table are detailed in Figure 7. 

TOS DEFINITION TABLE 

The TOS Definition table (701) (a flat file in a 
preferred embodiment) is created by the Network Administrator 
10 in charge of the Intranet. This table associates each 

Application Level Protocol with a Type Of Service value. The 
table contains a list of records (702), each record comprising 
the following information: 

♦ (703) Application_Level_Protocol (also referred to as 
15 ALP) . There is one value for each Application Level 

protocol. Typically, a record is defined for each of the 
main WWW protocols including Gopher, HTTP, FTP, Telnet, 
SSL (this is Secure HTTP) . 

♦ (704) TxjpejOf_Service (also referred to as TOS) . This is 
20 the value of the TOS associated with the Application 

Level Protocol (703) . This TOS value will be written in 
the TOS field of the IP Datagrams transporting the 
Application Level Protocol (703) over Socks. For 
instance, FTP can be associated with a TOS value of 0, 
25 while HTTP can be associated with a TOS value of 7. When 

the TOS field is then used within the Intranet to 
differentiate the Socks traffic, the HTTP traffic will be 
treated with a higher priority than the FTP traffic. 

The TOS Definition table also comprises default values 
30 (Type_ pf_Service default values) for ALP value is not 
explicitly defined in the table. 
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The Socks Connection table (705) is an internal table 
lilt by the Socks TOS~~ Client* I"lT~is used~ro — strore— the 
•iginator and the Type Of Service of each Socks connection. 
L e table contains a list of records (706), each record 
-oviding the following information: 

• (707) Cx_3ource_IP^Address . This is the IP address of the 
system which is the originator of the Socks connection 
(this system is called "originator" or "origin device"). 

• (708) Cx_Source_Port . This is the number of the Port 
identifying the program (the application) running on the 
origin device and which is the originator of the Socks 
connection 

• (709) Cx_ Dest_IP_Address. This is the IP address of the 
system which is the destination of the Socks connection 
(this system is called "destination" or "destination 
device" ) . 

• (710) Cx_Dest_Forfc. This is the number of the Port 
identifying the destination program (the application) 
running on the destination device ♦ 

The combination of Cx_Source_IP_Address , Cx_Source__Port, 
Cx_Dest_IP_Address, and Cx__Dest_Port identifies one and 
only one socks connection, 

• (711) CxJTOS. This is the value of the TOS field for the 
Socks connection uniquely identified by 
Cx_Source_IP_Address (707), Cx__Source_Port (708), 
Cx_Dest_IP Address (709) and Cx_Dest_Port (710). 

he combination of Cx_Source_IP_Address and Cx_Source_Port 
dentifies the source application running on the source device 
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at the origin of the socks connection. The combination of 
Cx__Dest_IP_Address and Cx__Dest_Port identifies the 
destination application running on the destination device at 
the destination of the socks connection. To identify a TCP 
5 connection (not only socks) , the combination of 

Cx_Source__lP_Addres s , Cx_Source_Por t , Cx_Des t__IP_Addres s , and 
Cx_Dest_Port must be used. 

TOS DEFINITION BUILDER 

The TOS Definition Builder component of the Socks TOS 
10 Client is preferably a computer program running on the end 

user workstation. This component is in charge of building the 
Socks Definition table (601) which associates each Application 
Level protocol with a TOS value. The TOS Definition Builder is 
the first component initialized when the Socks TOS Client is 
15 started on the end user workstation. Figure 8 is a flow chart 
which refers to the internal logic of the TOS Definition 
Builder component. This component: 

• (801) opens a connection, preferably a TCP connection, with 
the AutoTOS system (506) . The AutoTOS system is identified 

20 by means of a configuration parameter stored in the Socks 
TOS Client (preferably the IP Address of the AutoTOS 
system) . 

• (802) retrieves the TOS Definition table (803) from the 
AutoTOS system. Preferably, the protocol used to retrieve 

25 the table is FTP or HTTP. 

• (804) stores the TOS Definition table locally on the 
workstation (501) . 

• (805) closes the connection with the AutoTOS system. 

Optionally, the TOS Definition table can be manually 
30 placed on end user workstation instead of being retrieved from 
an AutoTOS system. 
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Optionally, the TOS Definition table is periodically 
updated. The TOS Definition Builder component can periodically 
retrieve the TOS Definition table from the AutoTOS system. An 
update of the TO"S~I^f lirrrion - taBle can - altso— b"e _ automat±caitiy- 
.5 sent to end user workstations by the AutoTOS system. 

SOCKS TRAFFIC ANALYSER 

The Socks Traffic Analyser component of the Socks TOS 
Client is preferably a computer program running on the end 
user workstation. This component is in charge of: 

10 • determining the Application Level protocol of each IP 
Datagram received by the Socks TOS Client, and 
• building the Socks Connection table (705) . 

Figure 9 is a flow chart which refers to the internal 
logic of the Socks Traffic Analyser component. This component: 

15 • (901) retrieves an IP Datagram from the TCP/IP Stack 
component . 

(902) tests whether the IP Datagram transports Socks traffic 
or not. The test preferably uses the Destination Port field 
of the TCP Header comprised in the Data part of the IP 

20 Datagram. The Destination Port is compared to the Port that 
uses the Socks protocol (by default, the Port used by Socks 
is 1080) . For instance, the Port used by the Socks protocol 
can be a configuration parameter of the Socks TOS Client. If 
the Destination Port in the TCP Header is equal to the Port 

25 used by Socks, then the IP Datagram transports Socks 

traffic, otherwise the IP Datagram does not transports Socks 
traffic and does not need to be processed by the Socks TOS 
Client . 

• If the IP Datagram does not transport Socks traffic: 
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• (903) the Socks TOS Client is not involved in the 
processing of non Socks traffic. The IP Datagram is 
directly returned to the TCP/IP Stack, which then sends 
it towards its destination. 

5 The processing by the Socks TOS Client of the IP 

Datagram is completed. The Socks TOS Client waits for 
the next IP Datagram. 

♦ If the IP Datagram transports Socks traffic: 

• (904) identifies the socks connection. The originator 
10 and the destination of the IP Datagram can be 

identified directly or by the information comprised in 
the IP Header and TCP Header: 

• Datagram__Source_IP_Address = Source IP Address field 
(in IP Header) . 

15 • Datagram_Source_Port = Source Port field (in TCP 

Header) . 

• Datagram_Dest_IP_Address = Dest IP Address field (in 
IP Header) . 

• Datagram_Dest__Port = Dest Port field (in TCP 
20 Header) . 

• (905) checks if the IP Datagram is a Socks CONNECT 
message. A Socks CONNECT message is identified by the 
CD field in the Application Level message (CD = 1) . 

• If the IP Datagram is a not a Socks CONNECT message: 

25 The IP Datagram therefore belongs to a Socks 

connection which is already established. This means 
that a CONNECT message has already been received and 
the corresponding record has been created in the 
Socks Connection table. 

30 • (906) calls the Socks TOS Finder component, 
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If the IP Datagram is a Socks CONNECT message: 
(907) determines from the IP Datagram (in the 



Destport field of the Socks CONNECT message) , the 
Application Level protocol (ALP) transported by 
5 the Socks connection: 

• Datagram_ALP = Destport field (in Socks CONNECT 
message) 

• (908) retrieves all records from the TOS 

Definition table (909). The table is preferably 
10 read only once for all and cached by the Socks 

Traffic Analyser at configuration time 7 in order 
to minimize the impact on performances. 

(910) finds the record corresponding to the 
Application Level protocol (ALP) of the IP 

15 Datagram. This is the record with: 

• Application_Level_Protocol = Datagram_ALP 

(911) determines from that record the TOS of the 
IP Datagram: 

• Datagram_TOS = Type_Of_Service 

20 • (912) saves in a new record within the Socks 

Connection table (913) the information for the 
Socks connection: 

• Cx_Source__IP_ Address = 

Da t ag r am_S our c e_I P_Addr e s s 
25 • Cx_Source__Port = Datagranu.Source_Port 

• Cx_Dest_IP__Address = Datagram_Dest_IP_Address 

• Cx__pest__Port = Datagram_J>est_Port 
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Cx__TOS = Datagram_TOS 



(9 06) calls the Socks TOS Finder component 



Optionally/ all IP Datagrams not comprising Socks data 
can also be processed by the Socks Traffic Analyser. In this 
5 case, the Datagram__ALP is identified by the Destination Port 
field in the TCP Header. 

SOCKS TOS FINDER 

The Socks TOS Finder component of the Socks TOS Client is 
preferably a computer program running on the end user 
10 workstation. This component determines a TOS value for each IP 
Datagram, using the Socks Connection table (705) . Figure 10 is 
a flow chart which refers to the internal logic of the Socks 
TOS Finder component. This component: 



Datagrarn_Source_IP_Address , the Datagram_Source_Port , the 
Datagram_Dest_IP_Address, and the Datagram_Dest__Port . 

• (1002) retrieves all records from the Socks Connection 
table (1003) . 



(1001) retrieves the IP Datagram forwarded by the Socks 



15 



Traffic Analyser component, along with the 



20 



(1004) finds the record which corresponds to the Socks 
connection. This record is identified by (four 
conditions) : 



Cx_Source_lP_Address = Datagram_Source_IP__Address 



Cx_Source_Port = Datagram_Source__Port 



25 



Cx_Dest_lP__Address = Datagram_Dest_IP__Address 



Cx__Dest_Port = Datagram__Dest__Port 



(1005) retrieves the Type Of Service (TOS) which 
corresponds to that Socks connection, from that record. 
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This is the value of the TOS field that must be written 
in the IP Datagram: 

♦ DatagramJTOS = Cx_TOS 



• (1006) removes from the Socks Connection table (1003) 
5 * records of closed Socks connections (terminated 

connections) . Closed Socks connections are detected for 
instance using the FIN and ACK indications in the TCP 
Header. Optionally, a Socks connection is considered 
"closed after a certain period of time without IP Datagram 

10 on that Socks connection (this timer value can be for 

instance a configuration parameter of the Socks TOS 
Client) . Any other existing algorithm to detect closed or 
half closed (for instance when one extremity of the 
connection has abnormally terminated) TCP connections can 

15 also be used to remove such connections from the table. 

• (1007) calls the Socks TOS Builder component 
SOCKS TOS BUILDER 

The Socks TOS Builder component of the Socks TOS Client 
20 is preferably a computer program running on the end user 
workstation. This component writes in the Type Of Service 
(TOS) field of each IP Datagram the TOS value determined by 
the Socks TOS Finder component. Figure 11 is a flow chart 
which refers to the internal logic of the Socks TOS Builder 
25 component. This component: 

• (1101) retrieves the IP Datagram forwarded by the Socks 
TOS Finder component, along with the Datagram__TOS . 

(1102) sets the TOS field of the IP Datagram with the 
Datagram_TOS . The Datagram_JTOS overwrites the value of 
30 the TOS field present in the received IP Datagram. 

Optionally (for instance by means of a configuration 
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information) , the TOS value written in the TOS field of 
the IP Datagram can be a combination of both: 

• the TOS value in the IP Datagram forwarded by the 
TCP/IP Stack, and 
5 • the TOS value determined by the Socks TOS Finder 

component . 

• (1103) calculates the new value of the Header Checksum 
field in the IP Datagram Header, The Header Checksum is a 
combination of all fields in the IP Datagram Header and 

10 is used by the destination of the IP Datagram to make 

sure that all fields in the IP Datagram Header have not 
been altered in the network. Since one of the IP Datagarm 
Header fields (the TOS) used to calculate the Header 
Checksum has been modified by the Socks TOS Builder, the 

15 Header Checksum received in the IP Datagram must be 

updated. The new value is calculated using the existing 
algorithm used by any program which builds IP Datagrams. 

(1104) writes the new value of the Header Checksum field 
in the IP Datagram. 

20 • (1105) forwards the IP Datagram to the TCP/IP Stack 

component. The. TCP/IP Stack then sends the IP Datagram 
towards its destination. The Socks TOS Client exits and 
waits for the next IP Datagram. 

ADVANTAGES 

25 The present inventions provides the following advantages 



♦ The Type Of Service (TOS) field of IP Datagrams is 

representative of the Application Level protocol used for 
transporting socks data. Any network device, such as a 
30 Dispatcher System, can use this TOS field for 

differentiating IP Datagrams according to the Application 

32 

- 1§ 
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Level protocol used for transporting Socks data. For 
instance, HTTP traffic for the WEB can. be set with a TOS 
value of 7, while batch FTP traffic can be set with a TOS 
value of 0. A Dispatcher System can then use the TOS field 
5 to dispatch: — ~ 

• HTTP traffic to a high capacity Socks Server, and 

• FTP traffic to a low capacity Socks Server with low 
capacity. 

Thus, an optimized response time and availability can be 
10 provided to HTTP traffic. 

• Network devices such as IP Routers may use the TOS field of 
the IP Datagrams to determine some IP Datagram 
characteristics such as the priority. Since the present 
invention associates a TOS value with the Application Level 

15 protocol, it therefore enables IP Routers to process IP 

Datagrams according to the Application Level protocol used 
by the Socks data they transport. For instance, IP Routers 
within the network may already process and route IP 
Datagrams with a TOS value of 7 faster than IP Datagrams 

20 with a TOS value of' 0. When HTTP is associated with TOS 7 
and FTP is associated with TOS 0, the IP Router will route 
and process faster the HTTP traffic. This mechanism provides 
an optimized response time for the HTTP WEB traffic. 

• The definition of TOS values according to the Application 
25 Level protocols used by Socks data (the TOS Definition 

table) can be centrally administered on the AutoTOS system. 
A Network Administrator can control said TOS Definition 
table for all end user workstations. 

• The Definition TOS table can be periodically and 

30 automatically retrieved from the AutoTOS system by the end 
user workstations. This way, updates of the TOS Definition 
table on the AutoTOS system (either manually by a Network 
Administrator or by automated processes) are automatically 
transferred to end user workstations. 
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For instance, in case of heavy network congestion, the TOS 
value for the Telnet traffic may be decreased from 5 to 0 
(assuming 0 corresponds to the lowest priority for IP 
Datagrams which can be discarded within the network) in the 
5 TOS Definition table located on the AutoTOS system. This 

updated TOS Definition table is then automatically retrieved 
by all end user workstations (or distributed to all end user 
workstations) . Thus, the Telnet traffic can be discarded 
within the network. As a consequence, the network congestion 
10 can be reduced and protocols with higher priority such as 
HTTP have a better chance to survive the congestion. 

• The association between TOS value and Application Level 
protocol (TOS Definition table) can be dynamically built 
when the end user workstation get connected to the AutoTOS 

15 system. Different TOS Definition tables can be returned to 
different end user workstations depending on some criteria 
such as the IP address of the end user workstation. 
For instance, one group of end users (groupO) may then use a 
TOS value of 0 for FTP, while another group of end users" 

20 (groupl) may use a TOS value of 1 for that same FTP 

protocol. IP Datagrams having a TOS value of 1 will be 
handled with a higher priority than IP Datagrams having a 
TOS value of 0. The FTP service provided to groupl will 
offer better performances than the FTP service provided to 

25 groupO . 

• The TOS value is written in the TOS field of IP Datagrams by 
end user workstations and not by any network device within 
the Intranet. Since companies usually own their end user 
workstations but may not own their intranet backbone 

30 network, it can be easier for them to implement a policy for 
associating TOS values and Application Level protocols on 
their end user workstations rather than on any network 
device. For instance, companies which do not own their 
Intranet backbone network but instead lease it from a 

35 Service Provider, can implement a policy on their end user 
workstations for said association. This way, they do not 
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have to rely on their Network Provider for providing such 
policy. 

• The TOS field in not modified within the network by the 

network-devices— (-such—as—: r-p-Routers-)-T^There— i-s— theref ore~no 

5 impact on the performance of these network devices. 

While the invention has been particularly shown and described 
with reference to a preferred embodiment, it will be 
understood that various changes in form and detail may be made 
therein without departing from the spirit, and scope of the 
10 invention. 
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Claims 



1. A method for setting the value of a Type of Service (TOS) 

rieia~nr"sn-liit^ 

the application protocol level of socks data (303) transported 
5 in said IP datagram, said IP datagram being sent from a source 
application on a source device to a destination application on 
a destination device, said method comprising the steps of c 

• identifying (1004) the source device address of the source 
device, 

10 • identifying (1004) the destination device address of the 

destination device, 

• identifying (1004) the source application address of the 
application on the source device, 

• identifying (1004) the destination application address of 
15 the application on the destination device, 

• determining (1005) a Type of Service (TOS) value referring 
to a first table (705), said first table comprising for each 
socks connection (706) identified by: 

• a source device address (707) , 

20 • a destination device address (709) , 

• a source application address (708) , and 

• a destination application address (710) , 

a Type Of Service (TOS) value (711) . 

• writing (1002) the Type Of Service (TOS) value in the Type 
25 Of Service (TOS) field (310) of the IP datagram (301) . 
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2 . The method according to the preceding claim wherein the IP 
datagram comprises a Source IP Address field (312) and a 
Destination IP Address field (313) in an IP header (302) and a 
Source Port field (314) and a Destination Port field (315) in 

5 a Transmission Control Protocol (TCP) header (305), 

the step of identifying (1004) the source device address of 
the source device comprising the further step of: 

♦ retrieving the source device address in the Source IP 
Address field (312) of said IP datagram, 

10 the step of identifying (1004) the destination device address 
of the destination device comprising the further step of: 

• retrieving the destination device address in the Destination 
IP Address field (313) of said IP datagram, 

the step of identifying (1004) the source application address 
15 of the application on the source device comprising the further 
step of: 

♦ retrieving the source application address in the Source Port 
field (314) of said IP datagram, 

the step of identifying (1004) the destination application 
20 address of the application on the destination device 
comprising the further step of: 

• retrieving the destination application address in the 
Destination Port field (315) of said IP datagram, 

3 . The method according to any one of the preceding claim 
25 wherein said step of determining (1005) a Type Of Service 

(TOS) value comprises the preliminary steps of: 
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• determining whether the IP datagram comprises a message for 
establishing a new socks connection, in particular a socks 
CONNECT message, or not, 



if the IP datagram comprises a message tor establishing a 
new socks connection, in particular a socks CONNECT message: 

• updating the first table (705) with the new socks 
connection identified by: 

• the source device address, 

• the destination device address, 

• the source application address, 

• the destination application address, 
of the IP datagram, 

• identifying (907) the application level protocol from the 
IP datagram, 

• determining (911) a Type of Service (TOS) value referring 
to a second table (701) , said second table comprising for 
each application level protocol (703) a Type Of Service 
(TOS) value (704) , 

• associating (912) in said first table (705) said socks 
connection (706) with said Type Of Service (TOS) value 
(711) . 

4 . The method according to any one of the preceding claims 
25 wherein said first table (705) is dynamic and comprises for 
each socks connection (706) : 

♦ a source device address (707) identifying the source device, 

• a source application address (708) identifying the source 
30 application, 
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• a destination device address (709) identifying the 
destination device, 

• a destination application address (710) identifying the 
destination application, 

5 • a Type Of Service (TOS) value (711) . 



5. The method according to any one of the preceding claims 
wherein said second table (701) comprises for each 
application level protocol (702) : 

• a Type Of Service (TOS) value (704) . 



10 6 . The method according to any one of the preceding claims 
comprising the initial steps of: 

• configuring (801.. 805) said second table (701), 

• defining a default Type Of Service (TOS) value for 
application level protocols not defined in said second 

15 table. 



7 . The method according to any one of the preceding claims 
wherein the step of configuring said second table (701) 
comprises the step of : 

• retrieving (802) said second table (701) from a server 
20 system (506) within the network. 



8. The method according to any one of the preceding claims 
wherein the step of configuring said second table (701) 
comprises the step of: 

• retrieving (802) updates of said second table (701) from 
. 25 said server system (506) within the network. 
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9 . The method according to any one of the preceding claims 
wherein the step of configuring said second table (7 01) 
comprises the step of: " ~~ 

♦ receiving said second table (701) from said server system 
5 (506) within the network. 

10. The method according to any one of the preceding claims 
wherein the step of configuring said second table (701) 
comprises the step of: 

• receiving updates of said second table (7 01) from said 
10 server system (506) within the network. 



11. The method according to any one of the preceding claims 
wherein the step of configuring said second table (7 01) 
comprises the step of: 

• locally storing (804) said second table (701) and/or updates 
15 of said second table within the source device. 



12. The method according to any one of the preceding claims 
wherein the IP datagram comprises a header checksum field 
(311) , said step of writing the Type Of Service (TOS) value in 
the Type Of Service field comprising the further step of: 

20 • computing (1103) the value of the header checksum field 
(311) according to the Type Of Service (TOS) value. 

• writing (1104) said computed value in the header checksum 
field (311) . 
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13. A system, in particular a source device (601), comprising 
means adapted for carrying out the method according to any one 
of the preceding claims. 



14. A computer readable medium comprising instructions for 
5 carrying out the method according to any one of claims 1 to 
12. 



FR 9 99 087 41 

BNSDOCID: <E1 994801 01 03> 



SYSTEM AND METHOD FOR ACCESSING A SOCKS SERVER FROM AN END 
USER WORKSTATION IN AN IP NETWORK 

Abstract 

The present invention discloses a method and system 
5 in a source device, in particular an end user workstation, for 
setting the value of a Type of Service (TOS) field in an 
Internet Protocol (IP) datagram (301) according to the 
application protocol level of socks data (303) transported in 
this IP datagram. The IP datagram is sent from a source 
10 application on a source device to a destination application on 
a destination device. The present method comprises the steps 
of: 

• identifying (1004) the source device, 

• identifying (1004) the destination device, 

15 • identifying (1004) the application on the source device, 

• identifying (1004) the application on the destination 
device, 

• determining (1005) a Type of Service (TOS) value referring 
to a first table (705) , said first table comprising for each 

20 socks connection (706) identified by: 

• a source device address (707), 

• a destination device address (709) , 

• a source application address (7 08) , and 

• a destination application address (710) , 
25 a Type Of Service (TOS) value (711). 

• writing (1002) the Type Of Service (TOS) value in the Type 
Of Service (TOS) field (310) of the IP datagram (301) . 



Figure 6 
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~~ Web" 
Browser 
(101) 



-HTTP-Request- 



HTTP Response 



(HTML, graphics, 
sound, video) 



-Socks- 
Server 
(104) 



HTTP Request 



HTTP Response 



(HTML, graphics, 
sound, video) .. 



Web 



Server 
(103) 



User Interface 
(102) 



FIG.1 



BNSOOCID:<E1 994801 01 03> 



2/11 



General Physical View of an End User Accessing the World-Wide-Web 
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Socks Client and Socks Servers 
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End User Workstation Retrieving TOS Definition 
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End User Workstation Processing the TOS Field 
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